Field of the Invention
This invention generally relates to identifier resolution and processing, and more specifically relates to methods, systems, products, and devices for processing domain name system friendly identifiers.
Description of the Related Art
A resource identifier such as a Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. URIs are the generic set of all names and addresses that refer to objects on the Internet. A URI can be further classified as a locator, a name, or both. A Uniform Resource Name (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. A Uniform Resource Locator (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network “location”), rather than identifying the resource by name or by some other attribute(s) of that resource.
A URL is the address of a file accessible on the Internet. The URL contains the name of the protocol required to access the resource, a domain name or IP address that identifies a specific computer on the Internet, and a hierarchical description of a file location on the computer. In addition, the last (optional) part of the URL may be a “query string” preceded by “?” or a “fragment identifier” preceded by “#”. The fragment identifier indicates a particular position within the specified file. For example the URL “http://www.example.com:80/index.html#appendix”, where “http” is the scheme or protocol, “www.example.com” is the host server name or Fully Qualified Domain Name (FQDN), “80” is the port connection for the HTTP server request, “index.html” is the filename located on the server, and “appendix” is the identifier to display a specific portion of the HTML file called “index”. The URL “http://www.example.com” also retrieves an HTML file called “index” on the HTTP server called “example.com”. By default, when either a port or filename is omitted upon accessing a HTTP server via a URL, the client browser interprets the request by connecting via port 80, and retrieving the HTML file called “index”.
Because an Internet address is a relatively long string of numbers (e.g., 31.41.59.26) that is difficult to remember, Internet users rely on domain names, memorable and sometimes catchy words corresponding to these numbers, in order to use e-mail and to connect to Internet sites on the Web. The Domain Name System (DNS) is a set of protocols and services on a network that allows users to utilize domain names when looking for other hosts (e.g., computers) on the network. The DNS is composed of a distributed database of names. The names in the DNS database establish a logical tree structure called the domain name space. Each node or domain in the domain name space is named and can contain subdomains. Domains and subdomains are grouped into zones to allow for distributed administration of the name space.
The DNS provides a mechanism so backup databases can be identified in case the first one becomes unavailable. DNS databases are updated automatically so that information on one name server does not remain out-of-date for long. A client of the DNS is called a resolver; revolvers are typically located in the application layer of the networking software of each Transmission Control Protocol/Internet Protocol (TCP/IP) capable machine. Users typically do not interact directly with the resolver. Application programs that use the DNS, such as mailers, mail servers, Web clients, Web servers, Web caches, IRC clients, FTP clients, distributed file systems, distributed databases, and almost all other applications on TCP/IP rely on the resolver library.
Resolvers query the DNS by directing queries at name servers, which contain parts of the distributed database that is accessed by using the DNS protocols to translate domain names into IP addresses needed for transmission of information across the network. The function of translating a domain name into an IP address is known as name resolution. Name resolution is performed by a distributed system of name servers having resolvers to fulfill the resource request of the client by the successive hierarchical querying of the resource records from zone files. Domain name resolution is explained in P. Mockapetris, “Informational RFC (Request for Comment) 1035: Domain Names—Implementation and Specification”, Internet Engineering Task Force (IETF), November 1987, “http://www.faqs.org/rfcs/rfc1035.html”. DNS friendly identifiers such as RFC 1035 compliant domain names are restricted to a limited 7 bit ASCII character set: A to Z, a to z, 0 to 9, and hyphen.
The Berkeley Internet Name Domain (BIND) implements an Internet name server for the UNIX operating system. The BIND includes a name server and a resolver library. BIND is fully integrated into UNIX network programs for use in storing and retrieving host names and addresses by calling a routine from the resolver library called gethostbyname( ) which returns the IP address corresponding to a given Internet host name. Error return status from gethostbyname( ) is indicated by return of a NULL pointer.
At the core of Netscape client products lies the Netscape Network library (NETLIB). A necessity of any network based client browser application is to send and receive data over a connection. This is accomplished in NETLIB by making a call to NET_GetURL( ). In order to resolve host names, NETLIB uses a standard DNS lookup mechanism. NET_FindAddress( ) makes the gethostbyname( ) call to lookup the IP address for the specified host from a DNS database stored on a DNS server, and is called from NET_BeginConnect( ). If a numeric IP address is passed into NET_FindAddress( ), it is passed directly into the gethostbyname( ) call which returns a success when an IP address is passed in. NET_FindAddress( ) is actually called repeatedly until it returns success or failure. Similarly, Microsoft Internet Explorer (MSIE) browser include objects such as WebBrowser Object and InternetExplorer Object, which contains events, methods, and properties. One event, called the Navigate Event navigates to a resource identified by a URL.
A domain name includes two parts: a host and a domain. Technically, the letters to the right of the “dot” (e.g., tlda.com) are referred to as Top Level Domains (TLDs), while hosts, computers with assigned IP addresses that are listed in specific TLD registries are known as second-level domains (SLDs). For the domain name “tlda.com”, “.com” is the TLD, and “tlda” is the SLD. Domain name space is the ordered hierarchical set of all possible domain names either in use or to be used for locating an IP address on the Internet. TLDs are known as top-level domains because they comprise the highest order name space available on the Internet. Second-level domains, as well as third-level domains (3LDs) such as “my.tlda.com”, are subsidiary to TLDs in the hierarchy of the Internet's DNS.
There are two types of top-level domains, generic and country code. Generic top-level domains (gTLDs) were created to allocate resources to the growing community of institutional networks, while country code top-level domains (ccTLDs) were created for use by each individual country, as deemed necessary. More than 240 national, or country-code TLDs (e.g., United States (.us), Japan (.jp), Germany (.de), etc.) are administered by their corresponding governments, or by private entities with the appropriate national government's acquiescence. A small set of gTLDs does not carry any national identifier, but denote the intended function of that portion of the domain space. For example, “.com” was established for commercial networks, “.org” for not-for-profit organizations, and “.net” for network gateways. The set of gTLDs was established early in the history of the DNS and has not been changed or augmented in recent years (COM, ORG, GOV, and MIL were created by January 1985, NET its July 1985, and INT was added in November 1988).
Incorporated and headquartered in California, the Internet Corporation for Assigned Names and Numbers (ICANN) is the non-profit corporation that was formed to take over responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions now performed under U.S. Government contract by Internet Assigned Numbers Authority (IANA) and other entities. The IANA, also headquartered in California, is the overall authority for day-to-day administration of the DNS. IANA staff carry out administrative responsibilities for the assignment of IP Addresses, Autonomous System Numbers, TLDs, and other unique parameters of the DNS and its protocols.
With respect to domain name management, the term “registry” refers to an entity responsible for managing allocation of domain names within a particular name space, such as a TLD. The registry stores information about registered domain names and associated name servers. The term “registrar” refers to any one of several entities with authority to add names to the registry for a name space. Entities that wish to register a domain name do so through a “registrar”. The term “registrant” refers to the entity registering the domain name. In some name spaces, the registry and registrar functions can be operated by the same entity, so as to combine the concepts and functions of the registrar and registry. The combined registry-registrar model is implemented in many ccTLDs and a few gTLDs.
VeriSign Global Registry Services (GRS) is the leading provider of domain name registry services and DNS support to the Internet and is responsible for the infrastructure that propagates this information throughout the Internet and responds to billions of DNS look-ups daily. Though there is a significant percentage of daily DNS look-ups that can not be resolved (e.g., can not find an IP address), there has never been any attempt by the registry or any other party to monetize from such unresolvable DNS requests.
The arbitrarily limited number of gTLDs has created a severe shortage of desirable domain names in the “.com” registry, leading to substantial pent-up demand for alternate domain name resources. Experimental registry systems offering name registration services in an alternate set of exclusive domains such as “.space” or “.love” developed as early as January 1996. Although visible to only a fraction of Internet users, alternate DNS systems such as the Name.Space, AlterNIC, and eDNS registries have contributed to the community's dialogue on the evolution of DNS administration. Competition argues that TLDs have become an issue of free speech and should not be restricted to the current limited set of gTLDs and ccTLDs.
Customers registering second-level domains in alternate TLDs cannot be reached by other Internet users because these domains, which are not listed in the root zone file, cannot be resolved by other Internet DNS name servers. Only if competitors individually negotiated with each of the scores of thousands of name server operators on the global Internet, something that is a physical and financial impossibility, for inclusion of alternate TLDs would there be any possibility that its domain names could be universally resolvable. As a result, competition has been unable to offer a commercially viable registration service in its TLDs, and has been unable to effectively compete in the domain name market. In March 2001, by partnering with several large ISPs to modify their nameservers, New.Net, Inc. opened their doors to serve as the most effective demonstration of how alternate TLDs are attempting to succeed in a fragmented market driven system.
The following excerpt is provided in, “Informational RFC (Request for Comment) 2826: IAB Technical Comment on the Unique DNS Root”, Internet Architecture Board, May 2000, “http://www.faqs.org/rfcs/rfc2826.html”. To remain a global network, the Internet requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root. This is a technical constraint inherent in the design of the DNS. Therefore it is not technically feasible for there to be more than one root in the public DNS. That one root must be supported by a set of coordinated root servers administered by a unique naming authority. Under agreements among ICANN, the U.S. Government, arm NSI, ICANN (through IANA, now absorbed into ICANN), sends documentation for needed changes to the root zone file to the U.S. Department of Commerce, which directs Network Solutions to implement them by editing the authoritative root zone file.
A supplemental memo to RFC 2826 is provided in Simon Higgs, “Informational Internet Draft: Root Zone Definitions”, Higgs Communications, May 2001, “http://www.ietf.org/internet-drafts/draft-higgs-root-defs-01.txt”. Within this memo, definitions are applied in an attempt to make other roots such as alternate or enhanced roots inclusive as part of a single, globally unique root implying that the single root comprises a plurality of root components distributed across many zone files. In another draft provided in Simon Higgs, “Informational Internet Draft: alternate Roots and the Virtual Inclusive Root”, May 29, 2001, “http://www.ietf.org/internet-drafts/draft-higgs-virtual-root-00.txt”, proposes a solution to the problem of duplicate colliding top level domains by identifying the virtual inclusive root (VIR), in compliance with the IAB's RFC 2826. Though the VIR is the sum of the consensus between all root zones on the public Internet, the VIR cannot support conflicting TLDs.
There is a particular increase in articles and publications emphasizing the importance of name space and the perceived shortage of “.com” names. References have been made that NASA is seeking authorization for “.mars” as an extension of terrestrial geography. Speaking on the opening day of the annual Internet Society (ISOC) conference in Geneva on Jul. 22, 1998. Vint Cerf, a founding President of ISOC, said the domain name debate should also encompass “.earth” or “.mars” because that's where real-time science data is going to travel from in the not-too-distant future. He said, “The idea is to take the interplanetary Internet design and make it a part of the infrastructure of the Mars mission.”
The main use of a web browser location field is for resolving URLs to locate and access resources. Entering a URL in the location field of a web browser serves as a means to access a network resource corresponding to that URL. Because the location field is essential for accessing resources, the design of such location fields have rivaled much competition and innovation between existing web browser products from companies such as Netscape and Microsoft. Improvements to better track and organize sites of URLs that users have visited such as Bookmark folders, URL history, and the personal toolbar are all examples of functionality designed to help users navigate. Other improvements include spell checking and an autocomplete feature from the URL history as text is entered into the location field.
A more recent feature called Smart Browsing is integrated into Netscape Navigator that uses Internet Keywords so users can streamline the use of URLs and get fast access to web sites using the browser's location field. Any single or multiword strings typed into the browser's location field that does not include a “.” are sent via HTTP to a server at “netscape.com”. The keyword server pulls the string and compares it to several separate lists of keyword-URL pairs. If the keyword system finds a match, it redirects the user's browser to the URL of the keyword-URL pair. Failing a match against the lists, the user's browser is redirected to a Netscape Search page with the typed string as the search query. The “.” versus “ ” is a key factor in determining what services are used. Depending on context, the detection of only a “.” delimiter implies a domain name for name resolution services whereas the detection of only a “ ” delimiter implies a search request for directory services and the like.
The autosearch feature of Microsoft Internet Explorer (MSIE) is another example of an improvement to the location field of a web browser. The details of the autosearch feature is disclosed in U.S. Pat. No. 6,009,459 issued on Dec. 28, 1999 by Belfiore, et al., entitled, “Intelligent automatic searching for resources in a distributed environment.” The '459 patent specifies a mechanism for a computer system to automatically and intelligently determine what a user intended when the user entered text within the location field of a web browser. Often users improperly enter URLs or enter search terms in a user interface element that requires URLs. If the user enters text that is not a URL, the system may first try to construct a valid URL from the user-entered text. If a valid URL cannot be constructed, the browser then automatically formats a search engine query using the user-entered text and forwards the query to an Internet search engine.
In addition, the '459 patent specifies a template registry that categorizes the specific suitability of a plurality of search engines to locate web sites related to a determined meaning of the specified text. The template is an entry in the registry that includes replaceable characters that may be replaced with the processed text. An example template registry entry that causes the Yahoo! search engine to be called is “http://msie.yahoo.com/autosearch?%s”. The %s is filled in with information regarding the search terms.
Because MSIE browser is more than an application and has become a de-facto infrastructure component, all attempts to compete with the Autosearch feature of MSIE browser include modifying a template in the operating system registry to redirect autosearch results usually to another search page. MSIE also includes an AutoScan feature. The AutoScan and AutoSearch features are dependent on each other in Internet Explorer 5 and can not be disabled from each other. Autosearch is tried first, and if there are no Autosearch results then Autoscan is tried. The Autoscan serves only as a navigation tool and has never been adapted/configured to perform other request types. There are no known applications capable of detecting the activation of the autosearch and in response either force the autosearch to terminate and invoke an autoscan request or perform a request that completely overrides the autosearch request.
The autosearch is typically configured to access various search engines. Unlike traditional search engines that list search results based on relevance, such as by website content, metatags and links to other sites, pay-for-placement search engines list results based on fees paid by listed sites. The legal debate over the use of trademarks as search terms in pay-for-placement search engines is related to the metatag debate of the 1990s. A series of cases in the fate 1990s and 2000 addressed the issue of whether the use of others' trademarks in a site's metatags constitutes trademark infringement. While no definitive rule emerged from these rulings, in a leading case, the Seventh Circuit found that use of others' trademarks as metatags indicates an intent to confuse consumers. Like trademark metatags, trademark search terms on pay-for-placement search engines may confuse users who do not realize they are being led to a competitor's site. There are currently no known systems that allow for the contemporaneous access to trademark information while processing a search engine request having one or more keywords. Additionally, there are no known methods for ordering search results based on trademark related metric that factors in URLs relating to intellectual property and/or trademark/servicemark/brand/information.
The autosearch is typically configured to access various search engines. Unlike traditional search engines that list search results based on relevance, such as by website content, metatags and links to other sites, pay-for-placement search engines list results based on fees paid by listed sites. The legal debate over the use of trademarks as search terms in pay-for-placement search engines is related to the metatag debate of the 1990s. A series of cases in the late 1990s and 2000 addressed the issue of whether the use of others' trademarks in a site's metatags constitutes trademark infringement. While no definitive rule emerged from these rulings, in a leading case, the Seventh Circuit found that use of others' trademarks as metatags indicates an intent to confuse consumers. Like trademark metatags, trademark search terms on pay-for-placement search engines may confuse users who do not realize they are being led to a competitor's site. There are currently no known systems that allow for the contemporaneous access to trademark information while processing a search engine request having one or more keywords. Additionally, there are no known methods for ordering search results based on trademark related metric that factors in URLs relating to intellectual property and/or trademark/servicemark/brand/information.
U.S. patent application Ser. No. 09/525,350 filed Mar. 15, 2000, by Schneider, entitled “Method, product, and apparatus for requesting a network resource” teaches how a registration request may be processed (particularly from an autosearch) in response to determining that a network resource can not be located from an input identifier having a valid domain. U.S. patent application Ser. No. 09/532,500 filed Mar. 21, 2000, by Schneider, entitled “Fictitious domain name method, product, and apparatus”, teaches how a valid URI may be constructed, resolved, and accessed (particularly from an autosearch) in response to determining that an input identifier includes a non-compliant RFC1035 domain name (e.g., domain name is fictitious). Both applications teach how input having only “.” delimiters can be processed from an autosearch by performing a network resource request and/or registration request in response to a failed DNS resolution request.
In addition, U.S. Provisional Application Ser. No. 60/157,075 filed Oct. 1, 1999, by Schneider, entitled “Method and apparatus for integrating resource location and registration services of valid and fictitious domain names” and U.S. patent application Ser. No. 09/653,100 filed Aug. 31, 2000, by Schneider, entitled “Method, product, and apparatus for processing a data request”, teach how such resolution and registration methods of valid and fictitious identifiers including multilingual domain names can be integrated into a unified product, apparatus, and system. In effect, the autosearch feature has never been used for further processing of any kind in response to determining that a DNS friendly identifier is unresolvable.
Aside from processing search requests and keyword resolution requests instead of or before processing a DNS resolution request, there has been no known public disclosure of how the autosearch can be used to process request types in response to a failed DNS resolution request until a VeriSign press release, “VeriSign Announces Breakthrough in Web Navigation For Tens of Millions of Users Worldwide”, Jun. 20, 2001, “http://corporate.verisign.com/news/2001/pr_20010620.html”, which announces that “Internet users can now reach Web site destinations by typing domain names with characters used in their own languages into their Microsoft Internet Explorer 5.0 or higher browser software.” Using technology from RealNames Corporation, Microsoft modified a search function of MSIE to enable the International Domain Names to work without the use of special plug-ins or client software. This was followed by an Internet draft provided in Yves Arrouye, “IDN Resolution in Windows Internet Explorer 5.0 and Above”, Jul. 3, 2001, “http://www.ietf.org/internet-drafts/draft-arrouye-idn-ie5-resolution-00.txt”, describes how internationalized domain names (IDNs) are being resolved in MSIE. The document focuses on the different steps that are taken after a user enters an IDN in the address bar of IE, up to when the relevant Web page is displayed in the user's browser. Though all input identifiers having only a “.” delimiter have only recently been configured to pass from the autosearch to a RealNames keyword resolver, the only further processing currently implemented is limited to that of IDN resolution only with the display of an error message for all other input.
RealNames Keywords were activated in the MSIE browser pursuant to a distribution agreement with Microsoft, which Microsoft chose not to renew. On Jun. 28, 2002 the RealNames service had terminated, where keywords no longer resolve in the MSIE browser. Keyword navigation has always remained dependant upon a client web browser or to a client web browser add-on or plug-in product. Other techniques of keyword navigation that do not require browser modification remain unexplored.
The domain name system uses the domain “in-addr.arpa” to convert Internet addresses back to domain names. In a way, “in-addr.arpa” forms the root of a separate hierarchy. This hierarchy has been made part of the main domain name hierarchy just for implementation convenience. While syntactically, “in-addr.arpa” is a second level domain (SLD), functionally it is a zero level domain (ZLD) in the same way as the highest level “.” is a ZLD. Another example of how a ZLD may be used is explained in, P. Falstrom, “Informational RFC (Request for Comment) 2916: E.164 number and DNS”, Cisco Systems Inc., September 2000, “http://www.faqs.org/rfcs/rfc2916.html” by showing how DNS can be used for identifying available services connected to a single E.164 phone number. Through transformation of E.164 numbers (ENUM) into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR records in DNS, available services for a specific domain name can be discovered in a decentralized way with distributed management of the different levels in the lookup process. The domain “e164.arpa”, which serves as a ZLD is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers.
For example, the E.164 number “+1-216-555-1212” can be translated into the “2.1.2.1.5.5.5.6.1.2.1.e164.arpa” domain having a zone that includes NAPTR resource records to help determine which resource to access in response to the ENUM request, however it remains the onus of industry to adapt how, where, and when this transformation takes place. Currently, there are no known tools to adapt the web browser or similar network navigation device to be ENUM enabled. Though the E.164 identifier holds great promise, the expression of the identifier is based on an international standard that may be awkward and unintuitive for quick adaptation by the public. Similar identifiers that represent ENUM may be adapted by the public more readily. There has been evidence over the years of a quicker adoption to informally express a phone number in a syntax similar to an IP address such as “216.555.1212”, for example.
Identifiers may exist across multiple namespaces, all with different ownership and rules, and different naming authorities. As shown, there is a recent convergence of attempting to map identifiers across multiple namespaces to access network resources via the DNS. The most common technique for mapping such identifiers is to automatically and transparently transform the identifier in a user's applications before a DNS query is sent. This method does not make any change to the DNS nor require separate DNS name servers. Other examples are proposals which have suggested that modifications are made to the DNS servers to accommodate international domain names, for example. While the proposed solution could work, it requires major changes to the Internet as it exists today. Domain name servers around the globe, which number in the hundreds of thousands, would have to be changed or updated.
As explained in P. Mockapetris, “informational RFC (Request for Comment) 1034: DOMAIN NAMES—CONCEPTS AND FACILITIES”, Internet Engineering Task force (IETF), November 1987, “http://www.faqs.org/rfcs/rfc1034.html”, the principal activity of name servers is to answer standard queries. Both the query and its response are carried in a standard message format. A domain name identities a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records (RRs). The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.
RRs with owner names starting with the label “*” are called wildcard resource records. Wildcard RRs can be thought of as instructions for synthesizing RRs. When the appropriate conditions are met, the name server creates RRs with an owner name equal to the query name and content taken from the wildcard RRs. The only example of wildcard RR usage in RFC 1034 is that of e-mail aliasing. U.S. Pat. No. 6,442,602 issued on Aug. 27, 2002, by Choudhry, entitled “System and method for dynamic creation and management of virtual subdomain addresses”, discloses how a wildcard RR can be used to launch a server script in response to an unrecognized/unregistered subdomain name such as “virtualsubdomain.domain.com”. The script will resolve it and map it to http://www.domain.com/subdomain, or any other file on a web server which is actually registered.
Recently, ccTLD registries have used wildcard RRs to redirect a resolvable domain name back to the registration component of the registry to perform registration requests. Performing this technique in a gTLD zone file would cause conflict enabling the Registry to bypass competition among multiple registrars in this very public component of the Internet's underlying technology. As a result a wildcard RR has never been used in a gTLD zone file. Furthermore, due to the global public nature with respect to the root zone file of the single, authoritative root DNS server or any other root DNS server for that matter, a wildcard resource record never been used in a root zone file.
An emerging economy of names has created a politically controlled TLD space due to the technical constraint of the DNS having a single authoritative root. Though alternate roots have surfaced to provide alternate TLDs, such services are criticized by supporters of the single root that such implementations disrupt DNS stability and fragment the Internet. However, the same critics encourage competition under the assumption that all such competition will inevitably threaten the stability of the DNS. There has long been an unfulfilled need for processing domain names having TLDs that are not resolvable by a single authoritative public root. Though alternate root servers have been deployed to recognize alternate TLDs, there has been little incentive by industry to move in this direction for concern that using such domain names would confuse the public, fragment the Internet, etc. Now that conventional namespace solutions have been traversed and exhausted, industry is only first beginning to attempt and expand domain namespace by offering proposed solutions with identifiers having only the “.” delimiter.
Similar in approach to the fictitious domain name method disclosed in U.S. patent application Ser. No. 09/532,500 filed Mar. 21, 2000, by Schneider, U.S. Published Patent Application 20020073233, published on Jun. 13, 2002 by Gross, et al., entitled, “Systems and methods of accessing network resources” discloses a system for using client-based address conversion software to intercept a requested Internet address having a non-ICANN compliant TLD. This published application corresponds to software technology deployed by New.net in March 2001 on either the network level by partner ISPs or on individual client machines, to add “new TLD extensions” to the existing DNS for the Internet community to purchase and use domain names with extensions that were previously unavailable. Requests to display Web pages with New.net domain names are resolved by appending the additional extension “.new.net” onto the address. As a result, requests are automatically routed to New.net's DNS servers to determine the correct IP address of the computer hosting the Web page. However, there is no mention in the published application nor no mechanism in New.net's deployed technology to provide the opportunity to register or check availability of a domain name of any kind in response to determining that the domain name is not resolvable or that a network resource corresponding to the domain name can not be located. Furthermore, the “new.net” portion of the domain name space (e.g., zone flies) has never included the use of wildcard RRs.
U.S. patent application Ser. No. 09/682,133 filed Jul. 25, 2001, by Schneider, entitled “Method, product, and apparatus for requesting a network resource” teaches how to create a market driven registrar competition across all TLDs (e.g., ccTLDs, gTLDs, alternate TLDs, and the like) by providing domain name wildcard redirection, particularly in a gTLD zone file, and U.S. patent application Ser. No. 09/682,351 filed Aug. 23, 2001, by Schneider, entitled “Fictitious domain name method, system, product, and apparatus” discloses how to create a competitive market driven namespace provider system across all TLDAs by providing fictitious domain name wildcard redirection in a root zone file, in this case through a proposed infrastructure domain “tlda.arpa”. Though these patent applications show new methods of using DNS resource records in public zone files (e.g., root zone, TLD zone), further methods have since been constructed that will be shown in this instant invention.
Due to the perceived shortage of TLDs, the struggle to add new TLDs has enabled industry to overlook solutions for extending the use of the current domain name space. Such art clearly demonstrates that there is a need for a system to foster better use of domain name space. Accordingly, in light of the above, there is a strong need in the art for a system and method for enhancing how domain name space can be more extensively used on a network such as the Internet.